IlilillilPIIDIIIillllililHIilll 

US006480959B1 

(12) United States Patent oo) Patent No.: us 6,480,959 Bl 

Granger et al. (45) Date of Patent: Nov. 12, 2002 



(54) SOFTWARE SYSTEM AND ASSOCUTED 
METHODS FOR CONTROLLING THE USE 
OF COMPUTER PROGRAMS 

(75) Inventors: Mark J. Granger, Azusa, OA (US); 

Cyrus E. Smith, Monrovia, CA (US); 
Matthew L Hoffman, South Pasadena, 
CA (US) 

(73) Assignee: Jamama, LLC, Pasadena, CA (US) 

( * ) Notice: Subject to any disclaimer, the term of this 
patent is extended or adjusted under 35 
U.S.C. 154(b) by 0 days. 

(21) Appl. No.: 09/197,108 

(22) Filed: Nov. 20, 1998 

Related U.S. Application Data 

(60) Provisional application No. 60/067,850, filed on Dec, 5, 
1997. 

(51) Int. Cl7 G06F 12/14 

(52) U.S, CI 713/189; 713/200 

(58) Field of Search 380/201, 203, 

380/352, 37, 22, 187; 713/165, 190, 189, 
193, 191, 200 

(56) References Cited 

U.S. PATENT DOCUMENTS 

4,278,837 A 7/1981 Best 178/22.09 

4,446,519 A 5/1984 Thomas 364/300 

(List continued on next page.) 

FOREIGN PATENT DOCUMENTS 

AU WO 97/04394 2/1997 G06F/12/14 

CA WO 97/33216 9/1997 G06F/1/00 

US ' WO 97/36239 10/1997 G06F/12/14 

WO WO 99/01815 1/1999 G06F/9/44 

OTHER PUBLICATIONS 

Collberg, C, Thomborson, C, and Douglas Low, "A Tax- 
onomy of Obfuscating Transformations," Technical Report 



148, Department of Computer Science, University of Auck- 
land, Jul. 1997 (36 pages). 

(List continued on next page.) 



Primary Examiner — Matthew Smithers 

(74) Anorney, ^gent, or Firm — Knobbe, Martens, Olson & 

Bear, LLP 



(57) 



ABSTRACT 



Three methods arc disclosed for protecting software appli- 
cations from unauthorized distribution and use (piracy). The 
first method involves using values generated by a conven- 
tional ESD (Electronic Security Device) to encrypt and/or 
decrypt user data (such as a file) that is generated and used 
by the application. In a preferred embodiment, the user data 
is encrypted (such as during a write to memory) using values 
returned by the ESD, and the user data is later decrypted 
using like values returned by a software-implemented ESD 
simulator. The second and third methods involve the use of 
special development tools that make the task of analyzing 
the application's copy protection code (such as the code 
used to encrypt and/or decrypt user data) significantly more 
difficult. Specifically, the second method involves using 
pseudocode to implement some or all of the application's 
copy protection functions. The pseudocode for a given 
function is generated (preferably in encrypted form) from 
actual code using a special development tool, and is then 
imbedded within the application together with a correspond- 
ing pseudocode interpreter. The interpreter fetches, decrypts 
and executes the pseudocode when the function is called. 
Because no disassemblers or other development tools exist 
for analyzing the pseudocode, the task of analyzing the copy 
protection functions becomes significantly more complex. 
The third method involves the use of a special obfuscation 
tool to convert the code for selected copy-protection func- 
tions into unnecessarily long, inefficient sequences of 
machine code. In one implementation of the obfuscation 
tool, the developer can control the quantity of code that is 
generated by specifying one or more control parameters. The 
three methods can also be used to protect software license 
management systems from security attacks. 

50 Claims, 11 Drawing Sheets 
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SOFTWARE SYSTEM AND ASSOCIATED 
METHODS FOR CONTROLLING THE USE 
OF COMPUTER PROGRAMS 

RELATED APPLICAnONS 

This application claims the benefit of U.S. Provisional 
Appl. No. 60/067,850, filed Dec. 5, 1997. tiUed SYSTEM 
AND METHODS FOR CONTROLLING USE OF PRO- 
TECTED SOFTWARE. Filed concurrenUy with the present 
application are two related applications, titled USE OF 
PSEUDOCODE TO PROTECT SOFTWARE FROM 
UNAUTHORIZED USE and OBFUSCATION SYSTEM 
AND METHOD FOR CONCEALING DETAILS OF 
ANTI-PIRACY SCHEME, both of which share the same 
disclose as that of the present application. 

HELD OF THE INVENTION 

The present invention relates to methods for preventing 
the unauthorized distribution and use of computer programs. 
More particularly, the present invention relates to methods 
for impairing the abihty of software pirates to remove or 
disable the executable copy protection code, or other secu- 
rity code, within a computer program. 

BACKGROUND OF THE INVENTION 

Software products (applications) are highly vulnerable to 
unauthorized copying and use (piracy). Illegally copied 
applications are commonly distributed on a wide-scale basis 
over the Internet and via recordable CD-ROMs. Software 
developers lose billions of dollars per year as a result of such 
unauthorized copying and distribution. 

Software developers commonly iise a variety of different 
forms of copy protection to prevent others from illegally 
copying and using their products. One of the most robust 
methods involves the use of an Electronic Security Device 
(ESD) which attaches to a port of the end user's computer 
and communicates with the application. If the ESD is not 
attached to the user's computer, the application crashes or 
otherwise fails to operate properly. 

Typically, the ESD is in the form of an electronic circuit 
which receives a numerical "seed" value from the 
application, applies a hardware -implemented number calcu- 
lation algorithm to the seed value, and returns a "response" 
value to the apphcation. To test for the existence of the ESD, 
the application's copy protection code sends one or more 
seed values to the ESD and compares the resulting response 
values with expected response values. The expected values 
can be generated by the software developer at development 
time (such as through experimentation with the ESD), or can 
be generated "on-the-fly" during execution by implementing 
the ESD's number calculation algorithm (if known to the 
software developer) within the copy protection code. 

Another type of system for controlling the use of appli- 
cations involves iising a license management server to 
control the number of copies of an application that can 
concurrently run on a network. With this type of system, the 
application will run properly only if it has checked out an 
authorization certificate from the license management 
server. When a user launches the application on a worksta- 
tion of the network, the application requests an authorization 
certificate from the license server If less than the maximum 
authorized number of copies are currently running, the 
license server dispatches an encrypted certificate to the 
workstation to unlock the application. 

A variety of techniques also exist for making it more 
diflScull for pirates to analyze an application's copy protec- 
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tion or other security code. One such technique involves 
storing the application's executable code in an encrypted 
form to hide the details of the security scheme, and decrypt- 
ing the code as it is executed or loaded into memory. Another 
5 technique involves inserting "dummy" cnachinc instmctions 
within the application's machine code to throw-off disas- 
semblers. 

Despite the sophistication of modern ESDs, and the 
significant time dedicated by software developers to writing 

10 better copy protection code, software pirates are often able 
to defeat copy protection schemes with relative ease. This is 
commonly done by using the latest software development 
tools to locate and circumvent the application's copy pro- 
tection code. The modifications needed to remove or cir- 

15 cumvem the application's copy protection code are com- 
monly distributed by the pirate as a small, separate piece of 
code (patch). A user can execute the patch to create a 
modified (cracked) version of the apphcation which will run 
without the ESD, or which will otherwise operate without 

20 use of the copy protection scheme. Once a cracked version 
of a product becomes available, the software developer has 
lost much of its investment in its product. 

A stronger form of copy protection is therefore needed. 
Ideally, software developers should be able to add the copy 
protection code without considerable time or effort, yet the 
resulting protection scheme should be extremely difficult 
and time consuming to analyze and circumvent. 

SUMMARY OF THE INVENTION 

30 

The present invention provides three methods or "layers" 
for protecting software applications from unauthorized dis- 
tribution and use (piracy). Each method can be used inde- 
pendently of the others, although the methojds are preferably 

35 used in combination. 

The first method involves using values generated by a 
conventional ESD (Electronic Security Device) to encrypt 
and/or decrypt user data (such as a file) that is generated and 
used by the apphcation. In a preferred embodiment, the user 

40 data is encrypted (such as during a write to memory) using 
values returned by the ESD, and the user data is later 
decrypted using like values returned by a software- 
implemented ESD simulator. An important aspect of this 
method is that it does not rely on the use of comparisons to 

45 determine whether or not the ESD is attached. As a result, a 
pirate cannot disable the copy protection by simply modi- 
fying or removing code that compares response values to 
expected values. A related benefit is that the apphcation 
. continues to operate (although not properly) when no ESD 

50 is attached, making the task of identifying the copy protec- 
tion code considerably more difficult. 

The second and third methods involve the use of special 
development tools that make the task of analyzing the 
application's copy protection code (such as the code used to 

55 encrypt and/or decrypt user data in method 1) significantly 
more difficult. Specifically, the second method involves 
using pseudocode to implement some or all of the applica- 
tion's copy protection or other use -authorization functions. 
The pseudocode for a given function is generated 

60 (preferably in encrypted form) from actual code using a 
special development tool, and is then imbedded within the 
apphcation together with a corresponding pseudocode inter- 
preter. The interpreter fetches, decrypts and executes the 
pseudocode when the function is called. Because no disas- 

65 semblers or other development tools exist for analyzing the 
pseudocode, the task of analyzing the copy protection func- 
tions becomes significantly more complex. 
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The third method involves the use of a Special obfuscation The term "application" refers to the target program to 

tool which converts the code for selected copy -protection or which one or more copy protection schemes are being or 

other functions into unnecessarily long, relatively inefficient have been applied to deter unauthorized use. An application 

sequences of (obfuscated) machine code. For example, the may include multiple code modules, including modules that 
developer can convert a IK block of copy protection code 5 run remotely from one another. Examples of applications 

into a 500K block of code that performs the same function. include word processing programs, 3D animation programs, 

In one implementation of the obfuscation tool, the developer spreadsheet programs, online banking programs, and opcr- 

can control the quantity of code that is generated by spcci- ating systems. 

fying one or more control parameters. As with the The term "ESD" (Electronic Security Device) refers to an 
pseudocode method, the use of the obfuscation tool makes lo electronic device that communicates with an application to 

the task of evaluating the application's copy-protection provide protection against the use of imauthorized copies of 

functions considerably more difficult. the application. ESDs commonly attach to an external port 

The invention also provides various enhancements to the of a computer, and communicate with the application using 

above methods. One such enhancement, for example, code modules that are provided by the manufacturer of the 
involves the intertwining of copy-protection and non-copy- 15 ESD. An ESD can alternatively be implemented, for 

protection functions within a single block of obfuscated example, as a chip on the motherboard of the computer, or 

code or pseudocode. A non-copy-protection function that is as unit of the computer's microprocessor, 

necessary to the proper operation of the application is The term "user data" refers to data that is generated by an 

preferably used for this purpose, so that attempts to remove application (or a component thereof) based on the input of 

the block of code from the application will render the 20 ^ ^g^j. yj^^ j^^y include, for example, a document 

application inoperative. generated by a word processing program, a configuration file 

BRIEF DESCRIPTION OF THE DRAWINGS f ""^^'^^ " °P"*'*°S system, a matrix table generated 

by a 3D animation program, or a portion of any such items. 

FIGS. lA and IB illustrate respective processes for ^erm "high-level code" refers to textual code written 
encrypting and decrypting user data in accordance with one 25 -^^ ^ high-level programming language (such as C, C++, 

feature of the invention. Pascal or Java) that provides a level of abstraction from the 

FIG. 2 illustrates a process for generating a look-up table underlying machine language. High-level code is typically 

for use within an ESD simulator. non-processor-specific, meaning that it does not correspond 

FIGS. 3A and 3B illustrate respective processes for to a particular machine-level instruction set. In contrast, 

encrypting and decrypting the user data when a table -based "assembly code" is textual code written in the low-level 

ESD simulator is used on the decryption side. assembly language (a language in which machine-level 

FIG. 4 illustrates an application file that includes instructions are represented by mnemonic codes) of a par- 
encrypted pseudocode, and includes a pseudocode inter- ticular processor or famUy of processors. "Machine code" 
preter that reads and processes the encrypted pseudocode. refers to the low-level numerical (binary) code that is 

HGS. 5 and 6 illustrate two alternative methods for f^f/^tly retrieved and processed by a microprocessor, 

generating encrypted pseudocode. "Machine-level code refers gencraUy to code that is m 

r. J- u- I. -11 . . *u ■ * A*u either machine code or assembly code form. 

FIG. 7 is a flow diagram which illustrates the input and the ^ ^ ^ „ c ju.- 

outputs of an encrypting assembler. Th^ |f ™ "pseudocode refers to machme code that is 

1,^ „ . r. t-' i_ -11 * * *u 1 executed by a software-implemented processor. Typically 

nG. 8 IS a flow diagram which illustrates the general 40 the preferred embodiment described herein), the 

operation of the encrypting assembler of FIG. 7. pseudocode is written in the machine language of a non- 

HG. 9 is a flow chart which illustrates the general existent machine or processor, 

operation of an interpreter which process encrypted The term "copy protection code" refers to executable code 

pseudocode. (whether in high-level or low-level form) that implements an 

HG.- 10 is a flow diagram which illustrates a preferred authorization verification scheme to prevent or deter the use 

development process for implementing an application func- unauthorized copies of an application. Copy protection 

uon in obfuscated machine code, commonly includes code that communicates with an 

FIG. 11 is a flow chart which illustrates, in accordance eSD to confirm that the application is running on a computer 

with one embodiment of the invention, the operation of the ^^^i includes a valid ESD. In the preferred embodiment of 

de-optimizing cross-compfler of FIG. 10. the invention, the copy protection code also includes, among 

FIG. 12 illustrates a license management system in which other things, encryption code that encrypts and/or decrypts 

the encryption, pseudocode and obfuscation techniques of user data based on values returned by an ESD. 

the invention can be used to protect against security attacks. x^c terra "software developer" or "developer" refers to an 

Throughout the drawings, like reference numbers are used 55 individual or entity that develops applications. The term 

to reference components that are the same or functionally "pirate" refers to an individual or entity that is seeking to 

similar. In addition, a number followed by an apostrophe defeat a copy protection scheme that has been applied to an 

indicates that the referenced component is a functional application, such as by removing or modifying an applica- 

counterpart of a component with the same number (e.g., 30 tion's copy protection code to produce a "cracked" version 

and 30' represent functional counterparts). that runs properly, without the use of an ESD. 

DETAILED DESCRIPTION OF THE Other terms are inu-oduced and defined throughout the 

PREFERRED EMBODIMENTS detailed description. 

I. Terminology ^L Branch-Level Copy Protection 

As used hereinafter, the following terms have the follow- 65 To facilitate the reader^s understanding of the invention, 

ing meanings (except where specifically indicated a prevalent technique for using an ESD to provide copy 

otherwise): protection wiU initially be described. 
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As indicated above, an ESD typically Operates by receiv- through software. These techniques can also be used to 

ing a seed value from the application and returning a protect network-based license management systems from 

corresponding response value to the application. The tampering. 

response value is commonly generated by the ESD by The three techniques can be viewed as three separate 

applying a one-way hash function or similar number calcu- 5 "layers" of protection. These layers are referred to herein as 

lation function to the seed value. With many ESDs, the the Encryption Layer, the Pseudocode Layer, and the Obfiis- 

software developer can pre -program the ESD's number cation Layer. Each layer can be used independently of the 

calculation function by storing a secret value within the ESD others, and only one of the layers (the Encryption Layer) 

before the device is shipped. requires the use of an ESD. In the preferred embodiment, the 

To protect a software application using the pre- 10 Encryption Layer is used in combination with either or both 

programmed ESD, the software developer typically inter- of the Pseudocode and Obfuscation Layers. Each of the three 

sperses calls to the ESD throughout the application's source j^V^^s is summarized below and is described in further detail 

code using seed values for which the corresponding ^" subsequent sections. 

response values are already known. Each time a call to the The Encryption Layer involves the use of copy protection 

ESD is made, the application compares the response value 15 code which communicates with an ESD. As with prior art 

to the expected response value. If the ESD returns an techniques, the copy protection code sends seed values to the 

unexpected value (or fails to respond) during program ESD and receives response values from the ESD. In contrast 

execution (indicating that there is not an authorized ESD Prior art techniques, however, the response values are not 

attached to the computer), the application will typically shut compared to expected values to determine whether a valid 

down or display an appropriate warning message. The 20 ESD is attached. Rather, the response values are used by the 

expected response values can be generated by the software application's copy protection code as a key for encrypting 

developer during the development of the application by and/or decrypting user data that is generated and used by the 

writing a small utility that sends seed values to the pre- application. (As described below, a software- implemented 

programmed ESD and records the response values that are ESD simulator is preferably used in place of the ESD to 

returned. 25 ^^^^^^^^ either the encryption key or the decryption key). 

A variation of the above approach involves implementing The user data may, for example, be a row of a spread sheet 

the number calculation function within the application code document generated by a spreadsheet application, or may be 

to provide an ESD simulator. This approach is normally ^ document generated by a word processmg program. An 

possible only if the software developer has access to the hash important characteristic of such data is that it changes from 

or other number calculation algorithm used by the ESD. 30 use to use of the application based on the actions of the user. 

When this approach is used, source code is included within The user data may be encrypted, for example, when the data 

the application to generate and send random seed values to ^ written to RAM (random access memory) or mass storage, 

both the ESD and the ESD simulator. The respective values and may be decrypted when the data is subsequently 

returned by the ESD and the ESD simulator are compared by retrieved or accessed by the application. User data is also 

the application's copy protection code to determine whether 35 preferably used to generate the seed value that is sent to the 

a valid ESD is attached. ESD (or ESD simulator). 

The above-described techniques are referred to herein as ^ important aspect of this method is that it does not rely 

"branch-level" copy protection, since they involve branches ^^e use of comparisons to determine whether or not the 

that are contingent upon the outcome of a numerical com- ESD is attached. (A single comparison is preferably per- 

parison. In practice, pirates have been able to disable 40 formed when the application is launched so that the user can 

branch-level copy protection schemes with relative ease. To t>e informed when the ESD is not properly attached.) As a 

disable a branch-level copy protection scheme, the pirate can result, a pirate cannot disable the copy protection by simply 

use commercially-available software development tools to modifying or removing code that compares response values 

locate aU of the calls to the ESD. This may be done, for expected values. A related benefit is that the application 

example, by using a commercially-available debugger pro- 45 continues to operate (although not properiy) when no ESD 

gram to monitor accesses to memory addresses that corre- ^ attached. This makes it considerably more difficult for the 

spond to the ESD. Once the calls to the ESD have been P^^^^^ identify the copy protection code that needs to be 

located, the pirate can use a disassembler or other tool to disabled in order to crack the application. Another benefit is 

locate and remove the code that is used to compare the that the method can be used to protect a wide range of 

response values to the expected values. 50 different types of applications. 

The pirate can alternatively replace the calls to the ESD The Pseudocode Layer and the Obfuscation Uycr, as 

with code that emulates the ESD. If the application always "sed in the preferred embodiment, serve the purpose of 

sends the same seed values to the ESD, the pirate can make concealing the implementation details of the Encryption 

note of the response values that are returned by the ESD, and Layer from pirates. In the preferred embodiment, for 

then replace the calls with code that returns these numbers. 55 example, these layers are used (either alone or in 

If the application uses the random number approach, the combination) to hide the details of the algorithm used to 

pirate can attempt to reverse engineer or extract the code that encrypt and decrypt the user data. As will be apparent, 

implements the ESD's number calculation algorithm, and however, the techniques used to implement the Pseudocode 

then replace the calls to the ESD with code that implements Layer and the Obfuscation Uyer can be used to hide the 

the algorithm. details of other types of copy protection schemes, including 

As described below, the copy protection methods of the ^^at do not involve the use of an ESD. For example, 

present invention overcome these and other weaknesses in ^^ese techniques could be used to hide the comparisons that 

prior art approaches performed in conventional branch- level copy protection, 

or could be used to hide the algorithm of a decryption engine 

111. Overview t^at decrypts executable code. 

The present invention provides three separate copy pro- The Pseudocode Layer involves the use of pseudocode to 

tection techniques, all of which are implemented entirely implement important copy protection functions of the appli- 
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cation. The pseudocode is preferably written in a language 
of a non-existent machine or microprocessor, so that pirates 
cannot use commercially-available software development • 
tools to disassemble and evaluate such copy protection 
functions. 5 

In one irapleraentalion, the Encryption Layer code which 
performs the encryption and decryption of user data is 
written in pseudocode. The pseudocode is preferably imbed- 
ded within the application code as an encrypted data table, 
together with data constants and temporary variables that are 
used by the code. During execution of the application, a 
pseudocode interpreter (also imbedded within the 
application) decrypts and processes the pseudocode line-by- 
line to perform the underlying copy protection functions. 
Because no disassemblers, debuggers, or other development 15 
tools are available to pirates for analyzing the pseudocode, 
pirates cannot analyze the important copy protection func- 
tions using their usual techniques. 

To use this method, the software developer initially 
selects the copy protection function or functions that are to 
be implemented in pseudocode. One or more non-copy- 
protection functions may also be selected to make it more 
diflScult for pirates to identify the application's copy pro- 
tection code. Because the use of pseudocode produces a 
degradation in performance, it is preferable to select func- ^ 
tions for which performance is not a significant concern. For 
example, a function that is called only on an occasional basis 
will typically be a better candidate than a function that is 
called on every pass of a heavily -executed program loop. 

Once appropriate fuiictions have been selected, the devel- 
oper generates the pseudocode for each function. This is 
preferably accomplished using one of two methods. The first 
method involves initially writing the code for implementing 
each selected function in a speci?il assembly language which ^5 
corresponds to pseudocode language. This assembly lan- 
guage code is then passed through a special pseudocode 
assembler which translates the special assembly code into 
encrypted pseudocode. Existing implementations of such an 
assembler (referred to as the "EASM") and a corresponding ^ 
interpreter (referred to as the "SPEC") that are capable of 
running under the Mac OS, Windows NT, Unix and other 
operating systems are described in detail below. In practice, 
the assembler and the interpreter may be maintained by the 
software developer as internal, proprietary development 
tools so that the details of the pseudocode/interpreter imple- 
mentation are maintained in confidence. Alternatively, a 
publicly-available assembler and interpreter can be provided 
that enable software developers to freely modify the imple- 
mentation details (such as the pseudocode instmction set) by 
adjusting configuration settings. 

The second method of generating the pseudocode 
involves the use of a special compiler which generates the 
encrypted pseudocode. With this method, the code for 
implementing the selected function is initially written in a 55 
high-level language, and is then compiled to generate the 
pseudocode. As with the assembler method, the compiler 
can either be a proprietary development tool of the software 
developer, or can be a commercially-available tool that 
enables software developers to modify the pseudocode 59 
implementation. 

The Obfuscation Layer involves the use of a special 
development tool to translate selected blocks of the copy- 
protection code (and possibly other types of code) into much 
larger, less efficient blocks of code, so that the pirate has to 65 
disassemble and analyze significantly greater amounts of 
machine code to extract the function(s) or algorithm(s) 
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performed by such code. For example, a 5K (kilobyte) block 
of machine code that implements an encryption algorithm 
(such as the algorithm used to encrypt user data) can be 
converted into a lOOK block of machine code that imple- 
ments the same algorithm. The pirate would then have to 
disassemble and analyze the entire lOOK block of machine 
code to extract the algorithm. 

This process of translating blocks of code into equivalent, 
less efiBcient blocks of code is referred to herein as "de- 
optimizing obfuscation/' The code generated by this process 
(whether in high-level or low-level form) is referred to 
generally as "obfuscated code," and is referred to more 
specifically as "obfuscated machine code" when in the 
machine -language form. The development tool used to gen- 
erate the obfuscated code is referred to generically as the 
"obfuscation tool." As described below, the de-optimizing 
obfuscation process can be performed either on the high- 
level code or the corresponding low-level code to ultimately 
produce obfuscated machine code. 

The obfuscation tool generates the obfuscated code at 
least in -part by converting pre-spedfied types of operations 
into equivalent operations that involve greater numbers of 
machine -level instructions. For example, the obfuscation 
tool may be configured to translate the mathematical opera- 
tion C=A+B into cither of the following equivalent 
sequences of operations: X=A/2, Y=B/2, C=2X+2Y; or 
C=2A, B«2B, C'=(C+B)/2. Non-math such as logical opera- 
tions and moves of data between registers and memory, can 
similarly be translated into less efficient, equivalent opera- 
tions. For example, a register-to-register move can be trans- 
lated into a register-to-memory move followed by a 
memory-to-rcgister move. The de-optimizing obfuscation 
process can be repeated any number of times to further 
increase the number of lines of code (and thus the level of 
obfuscation). Thus, for example, a single line of code can be 
converted into 1,000 or 1,000,000 lines of code, all of which 
are executed to perform the equivalent operation. 

Various methods exist for generating the obfuscated code, 
each of which involves a different type of obfuscation tool. 
In the preferred embodiment, the function to be imple- 
mented through obfuscated code is initially written in a 
high-level programming language. The resulting block of 
high-level code is then processed with a special, 
de-optimizing cross-compiler (the obfuscation tool) one or 
more times to generate a much larger block of obfuscated 
high-level code. The obfuscated high-level code is then 
compiled (using a regular compiler program) with the other 
application source code to generate the machine-level appli- 
cation code. During this second compilation process, the 
obfuscated high-level code compiles into a proportionally 
larger block of machine code than would result if the 
original high-level code were used. Thus, the process pro- 
duces obfuscated machine code that is considerably more 
complex and difficult to analyze. 

Another method involves the use of a de-optimizing 
compiler that converts the high-level code directly into 
obfuscated assembly or machine code. The obfuscated 
assembly or machine code is then imbedded within the 
application's source code files. Yet another method involves 
the use of a de-optimizing cross-assembler that converts a 
block of assembly code into obfuscated assembly code. 

Regardless of the method used, the obfuscation tool 
(de-optimizing compiler, de-optimizing cross assembler, 
etc.) preferably allows the' developer to enter one or more 
control parameters that specify the level of obfuscation. For 
example, in one embodiment, the developer can specify the 
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target ratio of the number of lines of obfuscated code to the ESDs by the software developer prior to shipping the ESDs 

number of lines of original code. Using this feature, the to customers, and is maintained in secrecy by the software 

developer can, for example, enter a target ratio of 1000 to developer. Because each of the 2*^ possible K-values makes 

effectively multiply the number of lines of code by 1000. An the hash function operate diflferently, knowledge of the hash 
important benefit of this feature is that it allows the devel- 5 function does not appreciably compromise security. ESDs of 

oper to select a level of obfuscation (code multiplication) this type are available from such companies as Rainbow 

that maintains the function's performance at an acceptable Technologies Inc. and Micro Macro Technologies Ltd, 

level. As with the Pseudocode Layer, the overall perfor- FIGS. 1 A and IB illustrates the Encryption Layer process 

mance of the application can also be controlled by appro- that is used to encrypt (FIG. lA) and decrypt (FIG. IB) the 
priately selecting the functions to be implemented in obfus- lO user data. This process is implemented by copy protection 

catcd machine code. code that is added to the application during the development 

The appropriate combination of the Encryption Layer process. As indicated above, the process can be implemented 

with either or both of the Pseudocode Layer and the Obfus- in-whole or in-part in pseudocode or obfuscated machine 

cation Layer produces an extremely high level of copy code. 

protection in which the implementation details of the 15 As depicted by FIG. 1 A, a block of user data is encrypted 
Encryption Layer are extremely difBcult to extract. An using a software -implemented encryption engine 30 to pro- 
important benefit of this mnlti-layered copy protection duce an encrypted block of user data. Any type and quantity 
method is that it is relatively simple for software developers of user data can be used for this purpose. For example, the 
to implement, particularly because the pseudocjode and block of user data may consist of the first 64 bytes of a file 
obfuscation techniques make use of easy-to-use, reusable 20 jjj^j is being written to mass storage, or may be a table entry 
development tools. Moreover, once the multi-layered that is being written to RAM. 

approach has been applied to an application, the implemen- y^e encryption engine 30 applies a key-based encryption 

talion can very easily be modified, such as when a new algorithm to the block of user data. Any of a variety of 

version of the application is released. For example, to encryption algorithms can be used for this purpose, 
change the encryption algorithm used to encrypt user data, 25 including, for example, DES, RSA, or an exclusive-OR 

the developer would simply rewrite the encryption function, (XOR) algorithm. More complex encryption algorithms 

and then convert the encryption function mto either such as RSA generally produce a higher degree of protection 

encrypted pseudocode (using either the pseudocode assem- expense of decreased performance, 

bier or the special compiler) or obfuscated code (using a ^ ^^^^ ^ .^^^^ encryption engine 30 

de-optmnzing compiler or other obfiiscation too ) The 30 user data based on a 64-bit seed value or "key" 

resulting code segment would then simply be compiled into generated by the ESD 32. As discussed below, a software- 

the application code. implemented ESD simulator may alternatively be used on 

The present invention also provides several techniques for either the encryption (FIG. 1 A) or decryption (FIG. IB) side 

further enhancing the level of copy protection provided by of the process. The key is generated by sending a 64-bit seed 

the three layers. One such technique involves combining the value to the ESD 32. Although FIGS. LA and IB depict a 

Pseudocode and Obfuscation Layers in a manner which scheme in which the ESD's response value is used as the 

produces a synergistic effect This may be done, for key, the response value could alternatively by combined 

example, by implementing selected portions of the inter- with other data, and/or further manipulated, to generate the ' 

preter in obfuscated code to make the task of reverse key. 

engineering the interpreter niore difficult; or by imbedding ^ ^^^^^ ^e a constant, or may be generated by 

an obfuscation tool within the pseudocode generator (e.g., ^^e application using an appropriate technique. Preferably, 

the pseudocode assembler or the special compiler) to pro- ^^e seed value is generated from a block of user data other 

duce obfuscated pseudocode. Another enhancement tech- j^,^ ^j^ck of data to be encrypted. For example, if the 

nique mvolves the intermmglmg of copy-protection and ^^^^^ ^^^^ ^ ^e encrypted is part of a file being 

non-copy-protection functions withm a single block of code, ^^tten to mass storage, another block of the file (such as the 

such as a block of pseudocode or a block of obfiiscated code. j^^j ^^^s) can be used as the seed. Alternatively, a portion 

Specific implementations and combinations of the of the file can be appropriately combined with other infor- 

Encryption Layer, the Pseudocode Layer and the Obfusca- mation (such as the version number of the application), 

tion Layer are described below. Throughout these and/or manipulated using a logic function, to produce the 

descriptions, reference will be made to various 64.bit seed value. Regardless of the technique used to 

implementation-specific details, including, for example, generate the seed, the application must be able to reproduce 

specific encryption algorithms, data structures, obfuscation the seed at decryption time so that the data block can be 

rules, and types and formats of pseudocode insU-uctions. properly decrypted. 

These details are provided in order to fully set forth a As depicted by FIG. IB, the process of decrypting the data 

preferred embodmient of the invention, and not to limit the ^lo^k is identical to the FIG. lA process except that a 

scope of the invention. The scope of the invention is set forth software-implemented decryption engine 30' is used in place 

m the appended claims. of ^^e encryption engine 30. The decryption engine 30' 

IV Th p f r implements a decryption algorithm which is the inverse of 

IV. ine lincryption Layer algorithm used to encrypt the user data. Because the 

Various types of commercially-available ESDs can be same seed value is used to generate the decryption key, the 

used to practice the features of the Encryption Layer In the decryption key is the same as the encryption key, and the 

preferred embodiment described below, an ESD that original block of user data is reproduced, 

receives a 64-bit seed value and returns a 64-bit response In implementing the above process, it is possible to use 
value is used. The response value is generated by the ESD 65 the ESD 32 during both the encryption phase (FIG. lA) and 

by applying a one-way hash function to the seed value and the decryption phase (FIG. IB). However, this would poten- 

a 64-bit "K-value." The K-value is programmed into the tially enable a pirate to circumvent the copy protection 
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scheme by replacing the code which queries the ESD (on simulator 32' has been generated using the process of FIG. 

both the encryption side and the decryption side) with a 2. With the exception of the ESD, all of the blocks shown in 

piece of code that always returns the same 64-bit response FIGS. 3A and 3B represent components of the application, 

value. It is therefore preferable to use an ESD simulator 32' As illustrated by FIG. 3A, a condenser 44 and an expander 
in place of the ESD 32 on either the encryption side or the 5 42 (both implemented in executable code of the application) 

decryption side of the process. An important benefit of this are added to the key generation process 45 on the encryption 

approach is that "calls" to ESD simulator arc significantly side to ensure that each seed value passed to the ESD 32 

more difficult for pirates to detect than calls to an actual corresponds to one of the 2*^* seed-response pairs repre- 

ESD. For purposes of the remaining description, it may be sented within the look-up table 32'. The function performed 
assumed that an ESD simulator is used during the decryption 10 by the expander 42 of FIG. 3A is identical to thai of the 

phase. expander of FIG. 2. In operation, each 64-bit seed value is 

The addition of the ESD simulator 32' to the application initially passed to the condenser 44. The condenser 44 

can be accomplished by adding code which impleraerits the translates each seed value it receives into a 14-bit value, and 

ESD's number calculation algorithm. This method requires passes the 14-bit value to the expander 42. The condenser 

the software developer to know the hash or other number may operate, for example, by simply bit-ANDing the 64-bit 

calculation algorithm implemented within the actual ESD. value with the constant 2FFFH. The expander 42 translates 

In addition, implementing the number calculation algorithm the 14-bit value back to a 64-bit value, and the resulting 

within the application increases the likelihood that a pirate 64-bit value is passed to the ESD as a seed. This seed value 

will be able to reverse engineer the algorithm (although the will always be one of the 2^^* seed values passed to the ESD 
Pseudocode Layer and Obfuscation Layer techniques can be 20 during the FIG. 2 table generation process. Thus, the 

used to hide the details of this algorithm). condenser/expander pair effectively maps each of the 2^^ 

It is therefore preferable to use a look-up table approach possible seed values into one of the 2^^* seed values repre- 

which involves the use of an encrypted look-up table of rented within the look-up table 48. The response value 

seed-response pains. As described below, the look-up table returned by the ESD is used to encrypt the block of user data 
can be generated by the developer without knowledge of the ^ ^he same manner as m FIG. lA. 

ESD's number calculation function. One advantage of the As illustrated by FIG. 3B, during the decryption phase the 

look-up table approach is that even if the pirate obtains seed value is similarly passed to a condenser 44 (which is 

access to the seed-response pairs in the look-up table, these identical to the condenser of FIG. 3A), and the output of the 

numbers will not reveal the number calculation algorithm of condenser is passed as a look-up table index to the ESD 

the ESD. simulator 32'. The ESD simulator 32' uses this 14-bit value 

Because it is not practical include all of the ESD's 2^"^ to retrieve the corresponding encrypted response value from 

seed-response pairs within the ESD simulator's look-up the look-up table 48, and decrypts the response value using 

table, a condensed look-up table that consists of a relatively a table decryptor 46'. The table decryptor 46' decrypts the 

smaU subset of seed-response pairs is used. As described response values using the key value that was used by the 

below, a condenser function is then used to ensure that seed table encryptor 46 (HG. 2). The output of the ESD simulator 

values passed to the actual ESD correspond to the seed- 32' is passed to the decryption engine 30' as the key for 

response pairs stored in the loop-up table. FIG. 2 illustrates decrypting the block of encrypted user data, 

the operation of a small utility which can be written and It will be appreciated that various alternatives to the 
executed during the development process to generate the ^ method of FIGS.3A and 38 are possible. For example, if the 

look-up table. The expander block 42 and the table encryptor user data involves a file being written to mass storage, a first 

block 46 represent functions that are performed by the block of the file could be encrypted using the ESD 32 and 

utility, and the look-up table 48 represents the output of the a second block of the file could be encrypted using the ESD 

utility. ' simulator 32'. During the decryption phase, the first block 

This utility operates generally by sending 2^''-16384 45 would then be decrypted using the ESD simulator, and the 

seed values to the ESD 32, encrypting the response values second block would be decrypted using the ESD. 

that are returned, and recording the 2^^* encrypted response The level of security provided by the technique of FIGS, 

values within the table 48. As depicted by blocks 40 and 42, 3A and 3B can be further improved by having the decryption 

the utility loops from 0 to 16,383, and in each pass of the portion of the code (and/or the encryption portion) perform 

loop, applies an expander function to a 14-bit loop counter, a useful calculation or other function that is part of the 

The expander 42 translates each of the loop counter values normal (non -copy-protection) operation of the application, 

into a unique 64-bit seed value to be passed to the ESD. A For example, if the application is a spreadsheet program, the 

simple approach to implementing the expander 42 is to function of multiplying the values of a spreadsheet array by 

multiply the 14-bit loop counter by a constant (such as a number N can be integrated into the application's encryp- 
2FFFH) to generate the 64-bit seed value. 55 tion and decryption code as follows. When the application is 

As illustrated by block 46 of FIG. 2, each of the 64-bit about to perform the multiply operation, the application can 

response values returned by the ESD 32 is encrypted before enter into the encryption phase, and during the encryption 

being stored in the look-up table 48. Any type of encryption phase, can multiply the array (i.e., multiply each value of the 

algorithm can be used for this purpose. Once the look-up array) by a random number R that is based on an ESD 
table 48 has been generated, both the look-up table and the 50 calculation. During the decryption phase, the decryption 

key used to perform the table encryption are imbedded code (e.g., the code used to implement the decryption engine 

within the application. ' 30') could multiply the array by N/R. This technique would 

HGS. 3A and 3B illustrate the modified process that is require the pirate not only to remove both the encryption 

used by the apphcation to encrypt (FIG. 3A) and decrypt code and the decryption code, but also to replace the 
(FIG. 3B) the block of user data when a table-based ESD 65 decryption code with code to multiply the array by .N. 

simulator 32' is used on the decryption side. It is assumed in This technique of intertwining copy protection and non- 

this illustration that the look-up table 48 used by the ESD copy-protection functions within the same routine is referred 
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to herein as "intermingling." Other types of functions that As illustrated in FIG. 4, the pseudocode for performing a 

can be intermingled with the encryption and decryption code given function (or possibly multiple functions) is preferably 

will be apparent to those skilled in the art. As described stored as an encrypted pseudocode ("ECODE'^ data block 

below, intermingling provides an extremely robust method 56 within a data table 58 of the executable appUcation file 

of copy protection when the intermingled code is provided 5 fio. Because the pseudocode is stored within a data table, the 

in pseudocode or obfuscated machine code. pseudocode appeare to the pirate simply as part of the 

The above-described Encryption Layer techniques can be application's data, and does not impair the operation of the 

used to protect virtually any type of apphcation or applica- pirate's disassembler or other analysis tool. The application 

tion component that generates and processes user data. If the file 60 also includes a self-contained pseudocode interpreter 

application includes one component that is used to generate 10 62 that decrypts and processes the ECODE data block to 

the user data and another component that is used at a remote "execute" the functions encoded therein. In a preferred 

site to process the user data, one component can conve- implementation which is described in detail below, the 

niently use the ESD while the other component uses the ESD interpreter emulates a non-existent 32-bit CPU (central 

simulator. This avoids the need to have multiple ESDs. processing unit). 

Although the Encryption Layer techniques (and particu- 15 As depicted in FIG. 4, the ECODE data block 56 prefer- 
larly the technique of FIGS. 3A and 3B) provide signifi- ably includes a header 66, any data 68 that is needed by the 
cantly greater security than is provided by conventional pseudocode, and the pseudocode instructions, all of which 
branch-level copy protection, it is possible that a dedicated are stored in encrypted, binary form. The header includes 
pirate could still remove the copy protection by reverse information that is used by the interpreter 63 to process the 
engineering the Encryption Layer components, ll is there- 20 ECODE data block 56, including an initial program counter 
fore desirable to have a mechanism for hiding the imple- setting of the emulated CPU, information about the argu- 
mentation details of these components. The Pseudocode ments to be passed, and key information for decrypting the 
Layer and the Obfuscation Layer provide two separate instructions 70. Although the ECODE data block 56 is 
mechanisms for hiding such details. preferably stored as a data table, the information contained 

With reference to FIGS. 3A and 3B, the primary compo- 25 within the data block could be stored in any of a variety of 

nents that include copy protection code for which it is forms, including separate files and application resources, 

desirable to hide the implementation details are the con- Although a single ECODE data block 56 is depicted in 

denser 44, the expander 42, the ESD simulator 32' (including pjQ ^ application file 60 can include multiple ECODE 

the table decryptor 46'), and the user data encryption and ^^^^ blocks, each of which may be stored as a separate data 

decryption engines 30, 30'. It is therefore preferable to 30 ^^^^^^ example, to implement the copy protection 

implement each of these components at least in-part either in scheme of FIGS. 3A and 3B, separate ECODE data blocks 

pseudocode or in obfuscated machine code. In general, only , provided for the condenser 44, the expander 42, the 

one of these two techniques (pseudocode or obfuscation) simulator 32' (including the table decryptor 46% the 

will be used to hide the details of a given software function, encryption engine 30, and the decryption engine 30'. 

although both techniques may be (and preferably are) used 35 ^^^^ ^^^^^^^ (non-copy-protection) functions of 

withm the same apphcation. application may also be implemented in pseudocode. 

V. The Pseudocode Layer This makes it more difficult for the pirate to identify and 

As indicated above, the Pseudocode Layer makes use of reverse engineer the code sequences that are used for copy 

pseudocode to implement one or more of the copy protection 40 Pr^^ction. For example, a pirate may spend a considerable 

functions of the application. The pseudocode is preferably in amount of time reverse engineering a pseudocode block only 

the form of binary machine code for a non-existent proces- to find out that the function performed by the block is 

sor or machine. unrelated to copy protection. 

As part of the pseudocode layer technique, the details of Another variation involves intermingling copy protection 
the pseudocode instruction set (including the opcodes and 45 and non-copy-protection functions within a single ECODE 
instruction formats) are maintained in secrecy by the soft- data block. For example, a single ECODE data code block 
ware developer An important benefit to using such can be provided that both encrypts user data (a copy- 
pseudocode is that no publicly-available debuggers, protection function) and writes non-encrypted user data to 
disassemblers, or other software development tools exist for memory (a non-copy-protection function). This technique 
analyzing the pseudocode. This makes it extremely difficult 50 makes it considerably more difficult for the pirate remove or 
for pirates to analyze the functions performed by the otherwise bypass the copy protection code, since bypassing 
pseudocode. As an enhancement to this method, the the ECODE data block would cause another function of the 
pseudocode is preferably stored within the appUcation in an application to fail. The non-copy-protection function may be 
encrypted form. a basic function that is necessary to the operation of the 

Although the pseudocode is preferably in the language of 55 application, so that removal of the ECODE data block 
a non-existent processor, it may alternatively be in the produces an inoperative apphcation. Alternatively, a non- 
language of an existing processor other than that of the copy-protection function can be used which, when removed 
platform to which the application has been ported. For (by removal of the ECODE block), merely causes the 
example a Macintosh application may, be provided with application to produce mmor or occasional mcorrect results, 
pseudocode (and an associated interpreter) for a PDP-11 60 This later approach makes it more difficult for the pirate to 
processor. This would have the advantage of allowing the determine whether the application has been successfully 
developer to test and debug the pseudocode on an existing cracked. 

machine. The drawback to this approach is that a pirate A function that is implemented in pseudocode may be 

could potentially identify the processor to which the invoked by another application function by calling the 

pseudocode corresponds, and use this information (and any 65 interpreter 62 and passing to the interpreter a pointer to the 

publicly-available development tools) to evaluate the ECODE data block to be processed. One or more arguments 

pseudocode's operation. may be passed to the interpreter as well. For example, if the 
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ECODE data block impiemeots the encryption engine 30 of 
FIG. 3A, the calling function may pass to the interpreter the 
64-bit key value and a pointer to the block of user data to be 
encrypted. 

As indicated above, the pseudocode used to implement a 5 
given function is preferably generated by the software 
developer using one of two methods. These two methods are 
illustrated in FIGS. 5 and 6, in which solid blocks represent 
development tools and dashed blocks represent components 
of the application being developed. As illustrated by FIG. 5, 
the first method involves hand-coding the function using a 
special assembly language that corresponds to the pseudo- 
processor (i.e., the processor emulated by the interpreter 62). 
The hand-coded assembly 80 is then processed using a 
special pseudocode assembler 82 to generate the ECODE 35 
data block 56. Aspecific implementation of the assembler 82 
is described below. The step of encrypting the data block can 
alternatively be performed after the assembly process using 
a separate encryption utility. 

The second method involves coding the function using a 
high-level language, and then using a special encrypting 
compiler 86 to convert the high-level code 88 into the 
ECODE data block 56. This method has the advantage of 
enabling the software developer to generate the pseudocode 
without the need to learn a special language. As with the finst ^ 
method^ the data block can alternatively be performed after 
the compilation process using a separate encryption utility. 

As indicated above, the assembler 82 and the encrypting 
compiler 86 can be maintained as confidential, internal 
development tools of the software developer to avoid expos- '^^ 
ing the implementation details of the pseudocode to poten- 
tial pirates. Alternatively, these tools (and the interpreter 62) 
can be written such that software developers can freely 
modify the details (opcodes, instruction formats, encryption 
methods, etc.) of the pseudocode so that the tools can be 
made publicly available. 

After the ECODE data block 56 has been generated (by 
either method), it is compiled together with the application's 
source code to imbed the ECODE as a data table. 

40 

As will be apparent from the foregoing, the use of 
pseudocode as described above provides a highly effective 
technique for hiding the implementation details of any 
software-based copy protection scheme. In order to analyze 
the functions that are coded in pseudocode, the pirate would 45 
normally have to disassemble and analyze the pseudocode 
interpreter 62, and then use the results of this process to 
write a disassembler for the pseudocode. At a minimum, it 
is believed that this would significantly increase the amount 
of time that it would take for a pirate to disable the copy 50 
protection scheme. 

In addition, even if a pirate successfully develops a 
pseudocode disassembler, the software developer can make 
minor changes to the pseudocode implementation (such as 
by changing the encryption method used to encrypt the ss 
pseudocode instructions, or changing instruction formats) to 
make the disassembler obsolete. The pirate would then have 
to repeat the process of analyzing the interpreter and writing 
a new disassembler. 

As indicated above, the level of concealment provided by 60 
the Pseudocode Layer can be further increased by appropri- 
ately combining the Pseudocode and Obfuscation Layer 
methods. One such combination involves implementing 
selected functions of the interpreter through obfuscated 
machine code, so that the interpreter will be more difficult to 65 
reverse engineer. Another combination involves including 
an obfuscation tool within the pseudocode generator (e.g., 
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the encrypting assembler 82 or the encrypting compiler 86) 
to enable the developer to generate obfuscated pseudocode 
as an option. 

Another enhancement involves using an interpreter that 
simulates a bit-slice processor This would involve writing 
microcode for the various macroinstructions that are needed, 
together with software for implementing the arithmetic logic 
unit and other processor components. This would make the 
task of reverse engineering the interpreter more difficult, as 
the pirate would generally have to evaluate the operation of 
the interpreter at the microcode level. As a further level of 
the protection, the microcode could be encrypted. 

The EASM (Encrypting Assembler) 
A preferred implementation of the encrypting pseudocode 
assembler 82, referred to as the "EASM" (Encrypting 
Assembler), will now be described. The interpreter which 
corresponds to the EASM is referred to as the "SPEC* 
(Software Processor for Encrypted Code). The SPEC emu- 
lates a 32-bit decrypting CPU which includes 16, 32-bit 
general purpose registers. The operation of the SPEC is 
described separately below. 

As depicted in FIG. 7, the EASM assembler 82 receives 
as its input a text file 80 which contains assembly code 
written in the EASM assembly language. The instruction set 
of the EASM assembly language consists of 59 instructions, 
including 6 jump instructions, 6 branch instructions, 25 
mathematical instructions, 4 logic instructions, 8 load/store 
instructions, 5 executive instructions, and a NOP instruction. 

The executive instructions are used to handle special 
cases relating to the supervisory control of the SPEC. For 
example, an EXIT instruction is used to instruct the SPEC to 
exit from the ECODE data block 56, and enables an optional 
value to be returned to the function that called the SPEC. 
The EXEC instruction instructs the SPEC to call an external 
function; two optional arguments can be passed to the 
external function, and a return value is placed into a SPEC 
register Other executive instructions are included for debug 
purposes. 

With further reference to FIG. 7, the outputs of the EASM 
are an X-REF (cross reference) file 90, a DIS (disassembly) 
file 92, and the ECODE data block 56. The X-REF and DIS 
files 90, 92 are used for debug purposes. The X-REF file 
includes a listing of label values, and the DIS file includes 
a disassembly of the entire code block with line numbers. 
The header 66 of the ECODE data block is encrypted by the 
EASM separately from the data and code portions 68, 70, 
and contains a key that is used by the SPEC to decrypt these 
portions. In one implementation, the EASM generates the 
key automatically based on the current time-of-day. As 
described below, the EASM uses an encryption technique in 
which each pseudocode instruction or data line is encrypted 
based on both the location (address) of the line in the table 
and a key value stored in the header 66. 

FIG. 8 is a flow chart which illustrates the basic operation 
of the EASM. As illustrated by the flow chart, the EASM 
operates generally by reading one line of the text file (block 
100), parsing the line (block 102), processing the parsed line 
to add data to a set of lists (header, data and code) that 
eventually become the ECODE data block (blocks 
104-112), and then reading the next line of the file (block 
100). After all of the lines of the text file have been 
processed, the EASM merges and encrypts the header, data 
and code lists (blocks 118 and 120) to generate the ECODE 
data block 56. 

Each line of the text file consists of either a macro, an 
instruction, or data. The macros are used to generate the 
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header 66, and are thus used by the developer to specify such 
things as the number of arguments, the initial program 
counter setting, and the key value for encrypting the data and 
instructions. As depicted by block 104, when one of the four 
built-in macros of the EASM is encountered, the EASM 5 
updates a header list and then loops back to read the next 
line. 

As depicted by blocks 108 and 110, if the EASM detects 
that .the line includes an instruction, the EASM's line parser 
generates a sequence of numeric tokens (3 for most 
instructions), each of which represents an element (label, 
instruction type, operand, etc) of the instruction line. The 
tokens are then used to build a pseudocode instruction. Each 
pseudocode instruction consists of 32 bits. The pseudocode 
instructions fall into five instruction formal categories. For 
each such category, the EASM has a corresponding internal" 
mapping macro that specifies how the opcode, operand(s) 
and any other bit fields are to be arranged within the 32-bit 
instruction value. 

To build a 32-bit instruction from a sequence of tokens, 
the EASM makes use of a token reader (not shown) that 
accesses an internal data structure (not shown). The EASM's 
token reader can read signed and unsigned data at different 
bit depths, and can decode labels, registers, decimal values, 
hex values and octal values. The internal data structure ^ 
defines the instruction set of the EASM, and specifies which 
of the five instruction formats is to be used to encode the 
assembly language instruction into a 32-bit pseudocode 
instruction. This data structure can be freely modified by the 
software developer to add and remove instructions and to 
change instruction formats. To add a new instruction to the 
EASM, the developer adds to this data structure a line which 
specifies the following: a text name of the instruction, a 
numeric opcode value, one of the five instruction formats 
(specified by a mapping macro), whether or not the instruc- "^^ 
tion is immediate, and whether the operand is signed or 
unsigned. A similar data structure is used by the SPEC to 
process the instructions. 

As the sequence of tokens for a given line is read, the ^ 
token reader matches the opcode to the corresponding 
instniction in the internal data structure to determine the 
instruction format and sign information. The token reader 
then parses the tokens, and maps the tokens (using the 
mapping macros) into the 32-bit pseudocode instruction. 
The pseudocode instruction is then written (in unencrypted 
form) to an instruction list which eventually becomes part of 
the ECODE data block. 

With reference to block 112, if the line consists of a data 
value, the data value is decoded and written into a DATA list, 

Once the last line of the text file has been processed, the 
EASM generates and writes the X-REF and DIS files (block 
116), and concatenates the header, data and instruction lists 
to form a single ECODE list (not shown). The EASM then 
encrypts the header portion of the EASM list using a header 55 
encryption algorithm (block 118), and then encrypts the data 
and code portions line-by-line using an instruction encryp- 
tion algorithm. These encryption algorithms can be specified 
by the developer from EASM's user interface. 

As described below, the SPEC decrypts and executes the 60 
instructions line -by-line. It is therefore desirable to use a 
relatively simple encryption algorithm to encrypt the 
instructions and data, since the use of a more complex 
algorithm would reduce instruction throughput. The algo- 
rithm used for this purpose is preferably a simple XOR 65 
algorithm that uses a key value stored in the header 66 and 
the position of the data/instruction line in the ECODE list. 
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As indicated above, the key value is generated automatically 
by the EASM. The header is preferably encrypted using a 
stronger encryption scheme such as DES. Because the 
header is only decrypted at the outset (as described below), 
the use of a stronger encryption algorithm for this purpose 
docs not affect instruction throughput. 

Once the ECODE block has been generated, the devel- 
oper can cut and paste the block into an application source 
code file. 

The SPEC (Software Processor for 
Encrypted Code) 

As indicated above, the SPEC is a self-contained inter- 
preter that emulates a 32-bit CPU in software. The SPEC is 
imbedded within the application to be protected, and is 
designed to decrypt and execute pseudocode instructions 
that were generated by the EASM. As with the EASM, the 
instruction set of the SPEC can be changed by simple 
modification to an internal data structure. The SPEC has no 
stack or other methods for memory allocation. A program 
counter (PC) of the SPEC references the line number (within 
the ECODE data block) of the instruction being processed. 

One feature of the SPEC is that it can write to the 
computer's local memory to access both data and instruc- 
tions. This allows self-modifying pseudocode to be used as 
an option. It is possible to overwrite the pseudocode instruc- 
tions in Macintosh implementations since the instructions 
are executed out of the data cache of the Power PC or other 
microprocessor. The use of self -modifying code makes it 
more difficult for pirates to analyze the operation of the 
pseudocode. 

Another feature of the SPEC is that it supports recursion 
(i.e., the abihty of a routine to call itself). Specifically, one 
SPEC function (a function implemented in SPEC 
pseudocode) can call itself or another SPEC function. As 
with self-modifying code, this feature can be used by 
software developers to further obscure the details of the 
copy protection scheme. 

In operation, the SPEC decrypts and processes an 
ECODE data block (generated by the EASM) that is stored 
in the computer's local memory. The location of the ECODE 
block is passed to the SPEC by the calling function via a 
pointer. The ECODE data block needs to reside in a modi- 
fiable partition if writing to local memory is required. 
Arguments can optionally be passed with the pointer, and 
have the effect of pre-loading SPEC registers. Arguments 
can represent pointers or numerical operands. 

FIG, 9 illxistrates the operation of the SPEC in further 
detail. When an ECODE data block is passed to the SPEC, 
the SPEC initially decrypts the header (block 130) to extract 
the initial PC setting, the number of arguments, and the key 
for decrypting data and instructions. Once the header has 
been decoded, the SPEC loads the registers (block 132) with 
any arguments and loads the PC with the line number of the 
first instruction to be fetched and executed. The SPEC then 
enters into a main fetch/execution loop (blocks 136-144). 

Within the execution loop, the SPEC retrieves one 
pseudocode instruction (block 136) at-a-time using the PC 
as an offset into the ECODE block. Once an instruction has 
been retrieved, the instruction is decrypted (block 138) using 
the PC value and the key extracted from the header. 
Pseudocode instructions can also be fetched from outside the 
ECODE data block (using direct addressing instructions), in 
which case the decryption step is bypassed. 

As depicted by block 140, the SPEC uses its internal data 
structure to decode the pseudocode instruction. If the 
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instruction is an EXEC instruction (block 142), the SPEC the present invention, conventional code obfuscators of this 

exits from the main felch/execution loop for special pro- type do not make the task of analyzing the operation of the 

cessing. Otherwise, the SPEC executes the instruction and machine code substantially more difficult, 

updates the PC (block 144). If the instruction involves a ^^^^S. 10 and 11 illustrate a preferred development pro- 
retrieval of data from the ECODE daU block 56, the data is 5 ^ for applying the Obfuscation Layer techniqiie to a 

decrypted using the same location-based method used to ff!"}?^ ^r'^*''Sr^e'in^ of fiinctions) of an application^ 

decrypt instrucUons. Likewise, if the instruction requires ^ohd blocks in FIGS^IO and 11 represent tools that are used 

J V L . T-r^r^T^r^ j . i_i i .l- j\ • by the devcloper, and dashed blocks represent compouents 

data to be written to the ECODE daU block, this data is of the appUcation being developed. As depicted by FIG. 10, 

mitially encrypted usmg the location based-method. If the ^J^^^ ^ initially manually coded in C to generate a C . 

instruction calls for data to be read from or written to an area lO ^^^.^^ ^^^^ y^is function may, for example, 

of memory outside the ECODE data block (which is pos- include code for implementing multiple smaller functions, 

sible when direct addressmg is used), no encryption or s^ch as a combination of copy -protection and non-copy 

decryption of the data is performed. protection functions that are intertwined. 

For all instructions other than branch and jump The C source code file 158 is then processed using a 
instructions, the PC is incremented by one to point to the 15 special de-optimizing cross-compiler 160 (the obfuscation 

next line of the ECODE data block. For branch and jump tool) to generate an obfuscated C source code file 162. In one 

instructions, the PC is loaded with an immediate value implementation, the special cross-compiler 160 recognizes 

specified within the instruction. only a simplified version of the C programming language, 

and this simplified version is used to manually code the 

VI. The Obfuscation Layer function. 

As indicated above, the Obfuscation Layer hides the In other embodiments of the invention, the obfuscation 

implementation details of selected copy protection or other tool 160 may, for example, output obfuscated machine-level 

software functions by implementing such functions using code (which may optionally be in a pseudocode language), 

unnecessarily large amounts of highly- inefiBcient (and thus or may output obfuscated code in a different high-level 
obfuscated) machine-level code. This technique makes it 25 language. Further, the obfuscation tool 160 may be config- 

more difficult for pirates to analyze such functions using urcd to accept a machine-level input file in place of the C 

conventional disassembly and debugging techniques. The source code file 158. 

obfuscated code is generated using an obfuscation tool The cross-compiler 160 preferably generates the obfus- 
which converts blocks of code into larger blocks of less cated C code by converting pre-specified types of operations 
efficient code under the control of the software developer. In (additions, multiplications, logical operations, moves, etc.) 
one embodiment (described below), the obfuscation tool is into larger numbers of constituent operations. As described 
in the form of a de -optimizing cross-compiler for the C below, this task may be performed at the machine level (as 
programming language. In another embodiment, the obfus- in the example provided below), at a higher level (such as 
cation tool operates generally as a de-optimizing cross- the C level), or both. The process of translating individual 
assembler that converts a block of assembly code into a operations into larger numbers of operations is governed by 
larger block of assembly code. a set of obfuscation rules that are stored in a rules library 
As indicated above, the Obfuscation Layer is preferably 180. For example, the mapping library 180 may contain a 
combined with the Encryption Layer by implementing one rule that specifies that the operation C=A+B is to be Con- 
or more of the following Encryption Layer components (all verted into the sequence C=2A, B==2B, C^C+B)/2. An 
shown in FIGS. 3 A and 3B), or portions thereof, in obfus- example set of obfuscation rules for generating obfuscated 
cated code: the condenser 44, the expander 42, the ESD ^ code at the machine level are provided in the example below, 
simulator 32' (including the table decryptor 46'), the cncryp- The cross-compiler 160 also preferably generates tables 
tion engine 30, and the decryption engine 30'. As with the that store input variables, temporary variables, constants, 
Pseudocode Layer, the level of copy protection provided by and other entities that are used by the obfuscated code, and 
the Obfuscation Layer can be increased by intermingling imbeds these tables within the obfuscated source code file 
copy-protection and non-copy protection functions within a 45 162. 

single, callable block of obfuscated code. In a preferred embodiment of the obfuscation tool 160, the 

By way of background, it is known in the art of program- software developer can define the obfuscation mles that are 

ming to use a code obfuscator program ("code obfuscator/*) to be used during the obfuscation process, and/or select a set 

to translate high-level source code into high-level source of obfuscation rules from a larger library of rules. This 
code that is more difficult to read. This is typically done (for 50 feature is useful, for example, for allowing the developer to 

non-copy-protection purposes) when a software developer modify the obfuscation process each time a new version of 

desires to provide its high-level application code to an the application is generated. A similar result can be 

outside entity to allow the entity to port the application to a achieved, for example, by providing an obfuscation tool 160 

specific hardware platform. To avoid unnecessarily exposing that selects the mles to be applied at random, and/or selects 

the algorithms and other implementation details of the the rules based on the input of the developer. This ability of 

application to the outside entity, the software developer uses the developer to control the obfuscation process by directly 

the code obfuscator to generate an obfuscated (less-human- or indirectly specifying the obfuscation rules to be tised 

readable) version of the high-level source code, and provides makes it practical for many different software companies to 

only the obfuscated version to the outside entity. use the same or similar obfuscation tools 160. 

Code obfuscators that are used for this purpose (exposing As depicted by the feedback path 168 in FIG. 10, the 
high-level source code to outsiders) operate by performing ^° obfuscation process may be re-applied to the obfuscated 

such tasks as replacing names of variables with arbitrarily- code any number of times to generate the desired amount of 

assigned character sequences, and merging multiple func- obfuscated code. For example, once the entire C source code 

tions into larger blocks of code. Importantly, when the file 158 has been processed to produce a block of obfuscated 

obfuscated source code is compiled, the resulting machine code, this block of obfuscated code can be processed a 
code is substantially the same in length and complexity as 65 second time to generate the obfuscated C source code file 

the machine code that would be produced from the non- 162. Any of a variety of techniques can be used to control 

obfuscated source code. Thus, unlike the obfuscation tool of the level of obfuscation. 
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In a preferred embodiment of the obfuscation tool 160, the 
developer can control the amount of code that is ultimately 
generated (and thus the obfuscation level) via a set of input 
parameters 170. The cross-compiler 160 then continues the 
obfuscation process (over multiple iterations if necessary) ^ 
until the target obfuscation level is reached. In one 
embodiment, for example, the developer specifies the target 
obfuscation level as a multiple of the original number of 
instructions. For example, if an obfuscation level of 100 is 
specified, the obfuscation tool 160 generates an output file 
162 having an instruction count that is at least 100 times the lO 
instruction count of the input file 158. In other 
implementations, the developer may, for example, specify 
the quantity of machine-level code to be generated, or 
simply specify the number of iterations to be performed 
before outputling the obfuscated code file 162. 

With further reference to FIG. 10, the obfuscated C source 
code file 162 (and any other such files that may be generated 
by the same process) is compiled together with the other 
application source code files 174 (using a regular C compiler 
176) to generate the application's machine code file(s) 178. 
During this process, the obfuscated C source code is trans- 
lated into a proportional quantity of obfuscated machine 
code. Thus, the obfuscation at the.C level translates into 
obfuscation at the machine level. The obfuscated functions 
are called during the execution of the application in the same 
manner as are non-obfuscated functions. 

FIG. 11 is a flow chart which illustrates one method that 
may be used by the dc-optimizing cross compiler 160 or 
other obfuscation tool to generate the obfuscated code. In 
this example implementation, individual instructions are 
translated into longer, equivalent sequences of instructions 
(referred to herein as "obfuscation sequences") at the 
machine level. In addition, only one machine-level instruc- 
tion is processed per iteration, and this machine-level 
instruction is selected at random. As will be apparent to 
those skilled in the art, numerous variations of the FIG, 11 
method are possible. 

As depicted by block 182 of FIG. 11, the high-level C 
code of the input file 158 is initially converted into machine- 
level code. The machine -level code may be in either 
machine code or assembly code form, and may be in the 
language of either an existing or a non-existing processor As 
depicted by block 184, during each iteration of the process, 
a machine-level instruction for which an obfuscation rule 
exists is selected at random, and the instruction is replaced 
with the corresponding obfuscation sequence defined by the 
rule. In one embodiment, if multiple rules exist for the same 
instruction, the obfuscation tool 160 selects one of the 45 
multiple rules at random. 

As depicted by decision block 186, the obfuscation tool 
160 determines, after each iteration, whether the desired 
level of obfuscation has been reached or exceeded. This may 
be accomplished, for example, by comparing the number of 50 
lines of code of a temporary output code structure to the 
number of lines of machine code generated in step 182. If the 
desired level has not yet been reached, the process of 
randomly selecting and replacing a machine-level instruc- 
tion is repeated. 55 

As depicted by block 188, once the desired obfuscation 
level has been reached, the resulting (obfuscated) machine- 
level code is preferably converted back to high-level code. 
This step is performed so that the resulting obfuscated code 
can be ported to multiple different hardware platforms. 
Alternatively, this step can be omitted, and the obfuscated 
machine-level code can simply be imbedded or compiled 
into the application— either as "regular" machine code, or as 
pseudocode to be processed by an imbedded interpreter. 

Obfuscation Example 

To illustrate the operation of an obfuscation tool 160 
which operates generally as depicted in FIG. 11, an example 
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will now be provided in which a simple C function is 
obfuscated using a set of machine-level obfuscation rules for 
a pseudocode language. In this example, it is assumed that 
the software developer has specified an obfuscation level of 
10, and that the obfuscation level is defined as a multiple of 
the initial number of machine-level instructions. 

The assembly language instructions and syntax used in 
this example are outlined in Table 1. The set of rules that are 
used are set forth in Table 2, in which the following macros 
are used: 

FRn — Generate an unused floating point register 

FCn — Generate a floating point constant 

In this example, two different rules (rules 2 and 3) are 
defined for the instruction add a, b, and these two alternative 
rules are selected by the obfuscation tool 160 at random. 

TABLE 1 

ASSEMBLY INSTRUCTIONS AND SYNTAX 



60 



Pneumonic 


Description 


NAME (lO, rl, . 


. . rn) Declare a function name with its list of 




parameters 


add a, b 


Add constant or register a to a constant or 




register b 


sub a, b 


Subtract constant or register a from constant oi 




register b 


mul a, b 


MuHtply constant or register a with constant or 




register b 


ret a 


Return from function with the result in 




register a 


mov a, b 


Move contents of register a to register b 



TABLE 2 



OBFUSCATION RULES 



Rule 



Instruction 
to be replaced 



Obfuscation 
sequence 



1 


mov a, b 


mov b, FRO 






add a, b 






sub FRO, b 


2 


add a, b 


mov FRO, FRl 






add a, FRO 






sub FRl, b 






add FRO, b 


3 


add a, b 


sub PCO +FCl,b 






add a, b 






add FCO, b 






add FCl. b 


4 


sub a, b 


move FRO, FRl 






sub a, FRO 






add b, FRl 






sub FRO, FRl 






mov FRl, b 


5 


mul a, b 


move FCO, FRO 






add a, FRO 






add FCl, FRO 






move b, FRl 






mul FCO + FCl, FRl 






mul FRO, b 






sub FRl, b 



The following C code is used in this example as the input 
function to be obfuscated: 
float function foo(a,b,c) 

{ 

return a*b+c; 

} . 

55 The assembly code for the this function is as follows: 
foo(fD.fl,£2): ;(a,b,c) 
mul a, fO ;a«a*b 
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add £2, fO ;a=a+c 
ret fO 

The initial function contains two machine -level instructions, 
not including the function declaration and return. In 
operation, the obfuscation rules are applied repeatedly to the 5 
function's instructions until the target obfuscation level is 
reached. As in the FIG. 11 implementation, one instruction 
is replaced (converted to an equivalent obfuscation 
sequence) per iteration, and the instructions are selected for 
replacement at random. The function's assembly code fol- 
lowing each iteration of the process is shown in Table 3, 
together with the rule applied during the iteration and the 
obfuscation level following the iteration. In each of the first 
five columns in Table 3, the instruction marked with an 
asterisk is the instruction randomly selected for replacement ^5 
in the following iteration. 

After iteration 5, the obfuscation level is 20/2»10, and the 
obfuscation process is complete. The final code now bears 
virtually no resemblance to the original pair of insUnclions. 
If this process were repeated until an obfuscation level of 20 
10,000, for example, were reached (resulting in approxi- 
mately 20,000 instructions), the task of examining the code 
to determine the function's purpose and operation would be 
extremely diflBcult. With modem processors, copy protection 
code that has been obfuscated to such a level can still be 25 
sufficiently efiBcient. 



rules that store temporary data on the stack, (b) rules that 
reorder instructions which do not depend upon each other's 
registers, (c) rules that reorder code with unconditional 
branching structures, (d) rules that add conditional branch- 
ing structures, (e) rules that add decoy instructions which 
operate upon unused registers, and (f) rules that randomize 
register numbers. 

VII. License Management 

The Encryption Layer, Pseudocode Layer and Obfusca- 
tion Layer techniques described above can also be used to 
protect' conventional license management systems from 
attack. FIG. 12 illustrates a typical license management 
system in which the techniques of the present invention can 
be employed. Software components for building systems of 
this type are available from such companies as Globetrotter 
Software Inc. of Campbell Calif. 

The system includes a central server 200 which commu- 
nicates with multiple workstations 202 over a local or wide 
area network (not shown) to control the use of an application 
206. Copies of the application 206 (one depicted in FIG. 12) 
are stored on the individual workstations 202 so that users of 
the workstations can selectively launch and run the appli- 
cation. In other implementations, the workstations 202 may, 
for example, be in the form of network computers that 
download copies of the application just prior to execution. 



TABLE 3 

[nitial Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 

Code (Rule S) (Rule 1) (Rule 2) (Rule 3) (Rule 4) 



mul fl, £0- 


mov 5, D 


mov 5, f3 


add £2, fO 


add fl, G 


add fl, f3* 




add 37, f3 


add 37, f3 




mov fO. f4* 


mov f4, f5 




mul 42, f4 


add fO, f4 




mul G, fO 


sub f5, f4 




sub f4, fO 


mul 42, f4 




add fZ, fO 


mul f3, ro 






sub f4, fO 






add f2, fO 



Obfuscation Obfuscation Obfuscation 
Level: 0 Level: 4 Level: 5.5 



mov 5, D 


mov 5, D 


mov 5, D 


mov f4, fS 


mov f4, f5 


mov f4, fS 


add £1, f4 


add fl, f4 


add fl, f4 


sub f5, f3 


sub f5. f3 


sub f5, D 


add f4, f3 


add f4, O 


add f4, D 


add 37, f3 


add 37, D 


add 37, f3 


mov f4, f5 


mov f4, f5 


mov f4, f5 


add fO, f4 


add fO, f4 


add fO, f4 


sub f5, f4 


sub f5, f4" 


mov (6, n 


mul 42, f4 


mul42, f4 


sub f5, f6 


mul f3, fO 


mul D, fO 


add f4, n 


sub f4, ft) 


sub f4, fD 


sub f6, f7 


add £2, fO* 


sub 11, fO 


mov V7, f4 




add f2. fD 


mul 42, f4 




add 3, ro 


mul f3, ra 




add 8, fD 


sub f4, fD 






sub 11, fD 






add f2, fD 






add 3, fO 






add 8, fO 


Obfuscation 


Obfuscation 


Obfuscation 


Level: 7 


Uvel: 8.5 


Level: 10 



•Instruction replaced on following iteration 



As described above, the obfuscated machine-level code 
can be converted back into C (or another platform- 
independent language), or can be imbedded or compiled 
directly into the application without first being converted 
into a high-level language. 

As will be appreciated by the foregoing, the general 
methodology used to replace machine-level instructions in 
the above example can also be used to replace instructions 
of a high-level code sequence. In addition, the technique can 
be used to obfuscate a function that has been hand-coded in 
an assembly language. 

It will also be appreciated that other types of obfuscation 
rules could additionally or alternatively be used to increase 
the level of security provided by this technique. Examples of 
other types of obfuscation rules include the following (a) 



The server 200 runs a license management server program 
208 ("LM server*') that dispatches encrypted authorization 
certificates to the workstations 202 in response to requests 
generated by the application 206. These requests are gener- 
ated by a license management client component 210 ("LM 
client") that is imbedded within the application code. Unless 
a valid authorization certificate has been dispatched to the 

^° LM client 210, the application 206 will remain in a locked 
(nonoperative) state on the workstation 202. 

As illustrated in FIG. 12, the LM server 206 accesses 
encrypted license data 212 that specifies the rights of the 
Ucensee (typically a corporate organization) to use the 

65 apphcation under a license arrangement This data may, for 
example, be stored locally on the server 200 (or elsewhere 
on the network) as an encrypted file. The license rights 
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Specified by such data 212 normally include the number of 
application copies that are authorized to run concurrently on 
the network. Other license rights that may be specified 
include the application features that users are authorized to 
access, the expiration date of the application, and license 
rights with respect to other applications. 

The LM server 208 also includes a certificate encoder 214 
and an encryption engine 216, The certificate encoder 214 
generates authorization certificates (blocks of encoded data) 
based on the encrypted license data 212. The encryption 
engine 216 encrypts these certificates before they are trans- 
mitted on the network. The LM client 210 includes a 
decryption engine 220 for decrypting the certificates, and 
includes a certificate processor 222 for decoding and pro- 
cessing the decrypted certificates. The certificate processor 
222 also includes functionality for unlocking the application 
206. 

In operation, when a user launches a copy of the appli- 
cation on a workstation 202, the application comes up in the 
locked state. In response to the launching of the application, 
the LM client 210 on the workstation generates a request for 
an authorization certificate and sends the request to the LM 
server 208. The LM server 208 keeps track of the number of 
copies of the application that are currently running on the 
network, and dispatches a certificate to the requesting work- 
station 202 only when this number is below the maximum. 
In some implementations, the dispatched certificate specifies 
the particular application features that the user is authorized 
to use, and the application 206 uses this information to 
enable or disable specific features. 

Upon receiving the authorization certificate at the work- 
station 202, the LM client 210 decrypts and decodes the 
certificate to ensure that the certificate is valid. If a valid 
certificate is received, the certificate processor 222 unlocks 
the application 206 on the workstation 202. When the user 
subsequently closes the application 206, the LM client 210 
notifies the LM server 208 that the certificate is no longer in 
use. The LM server 208 may also poll or otherwise com- 
municate with the application copies that have outstanding 
certificates to make sure each copy is still running (e.g., has 
not crashed). 

Systems of the type described above can be attacked by 
hackers in a number of different ways. One way is to modify 
the application code to enable the application to run without 
a valid authorization certificate. Another method is to 
modify either the encrypted license data 212 or the execut- 
able code of the LM server 202 to cause the LM server to 
dispatch more certificates than the licensee has paid for. Yet 
another method is to write a program that emulates the 
operation of the LM server 208. 

To protect against these and other forms of attack in 
accordance with the present invention, portions of the LM 
server and the application 206 are provided in pseudocode 
and/or obfuscated machine code (in the same manner as 
described above for standard copy protection) to hide the 
implementation details of the authorization scheme. 
Preferably, the code portions of the LM server 208 that are 
provided in pseudocode and/or obfuscated machine code 
include the following: the certificate encoder 214, the 
encryption engine 216, the code (not shown) used to decrypt 
and interpret the encrypted license data 212, and the code 
(not shown) used to poll the workstations 202. The code 
portions of the application 206 that are preferably provided 
in pseudocode or obfuscated machine code include the 
decryption engine 220, the certificate processor 222, and the 
code (not shown) that responds to poUs from the LM server 
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208. If pseudocode is used within the LM server 208, the 
LM server will include an imbedded pseudocode interpreter; 
and if pseudocode is used within the application 206, the 
application will include an imbedded pseudocode inter- 
5 preten 

ESDs can be used on the central server 200, the work- 
stations 202, or both to further increase the level of security. 
One method is to use an ESD on the central server 200 to 
encrypt the authorization certificates (using code within the 
10 LM server 208), and to use ESD simulators on the work- 
stations 202 to decrypt the certificates (using code within the 
application). This method is preferably implemented using 
the same process as shown in FIGS. 3A and 3B (with FIG. 
3A representing the LM server process and FIG. 3B repre- 
ss senting the application process), with the exception that the 
user data is replaced with the authorization certificate. 

Although this invention has been described in terms of 
certain preferred embodiments, other embodiments that are 
apparent to those or ordinary skill in the art are also within 
the scope of this invention. Accordingly, the scope of the 
present invention is intended to be defined only by reference 
to the appended claims. 

What is claimed is: 

1. A software application that runs on a computer in 
^ conjunction with an electronic security device (ESD), the 

application comprising, stored on a computer- read able 
medium: 

application code which generates user data based on the 
input of a user, and which retrieves and processes the 
user data; and 

copy protection code which communicates with the ESD, 
the copy protection code configured to encrypt and/or 
decrypt the user data using values generated by the 

35 ESD, the copy protection code thereby preventing the 
application from operating properly when the applica- 
tion is executed without the ESD; 
wherein the copy protection code includes an ESD simu- 
lator which simulates the operation of the ESD, and 

40 wherein the copy protection code further encrypts 
and/or decrypts the user data using values generated by 
the ESD simulator. 

2. The software application according to claim 1, wherein 
the user data that is encrypted and/or decrypted by the copy 

45 protection code comprises a portion of a file that is written 
by the application to a memory of the computer. 

3. The software application according to claim 2, wherein 
the copy protection code encrypts the user data as the file is 
written to memory, and decrypts the user data as the file is 

50 retrieved from memory. 

4. The software application according to claim 1, wherein 
at least a portion of the copy protection code is implemented 
in pseudocode, and wherein the application includes an 
interpreter which fetches and executes the pseudocode. 

55 5. The software application according to claim 4, wherein 
the pseudocode is in a machine language for which no 
publicly available software development tool exists at a time 
of authoring of the pseudocode portion. 

6. The software application according to claim 4, wherein 
60 the pseudocode is encrypted, and the interpreter decrypts the 

pseudocode for execution. 

7. The software application according to claim 4, wherein 
the pseudocode is stored within a data table of the applica- 
tion. 

65 8. The software application according to claim 1, wherein 
the copy protection code generates seed values using the 
user data, and sends the seed values to the ESD to cause the 
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ESD to generate the values that are used to encrypt and/or 
encrypt the user data. 

9. The software application according to claim 1, in 
combination with the ESD. 

10. The software application according to claim 9, 
wherein the ESD generates the values using a one-way hash 
function. 

11. The software application according to claim 1, 
wherein the copy protection code includes a copy protection 
function that is implemented in obfuscated machine code 
that has been generated using an obfuscalion tool. 

12. The software application according to claim 1, further 
comprising a module of obfuscated machine code that 
implements at least one copy-protection function and at least 
one non-copy-protection function, the non -copy -protection 
function essential to the proper operation of the application, 
the module of obfuscated machine code generated using an 
obfuscalion tool that controllably increases a quantity of 
machine code. 

13. The software application according to claim 1, 
wherein the ESD generates the values using a one-way hash 
function. 

14. The software application according to claim 1, 
wherein the user data comprises 3D animation data. 

15. A method of protecting a software application from 
unauthorized use, the software application adapted to gen- 
erate user data in response to actions of a user, the method 
comprising: 

providing the application with a code module which 
communicates with an electronic security device 
(ESD), the ESD configured to generate and return 
numeric values in response to requests; 

providing the application with a software -implemented 
ESD simulator which simulates an operation of the 
ESD; and 

providing the application with a software -implemented 
encryption/decryption engine which encrypts and 
decrypts user data generated by the application using 
values generated by the ESD and the ESD simulator. 

16. The method as in claim 15, wherein the step of 
providing an encryption/decryption engine comprises writ- 
ing at least a portion of the encryption/decryption engine in 
pseudocode, and providing, within the application, an inter- 
preter which fetches and executes the pseudocode. 

17. The method as in claim 16, wherein the step of 
providing an encryption/decryption engine further com- 
prises imbedding the pseudocode within a data table of the 
application. 

18. The method as in claim 17, wherein the step of 
imbedding comprises imbedding the pseudocode within the 
data table in an encrypted form. 

19. The method as in claim 15, further comprising pro- 
viding the application with a module of pseudocode and an 
interpreter which executes the pseudocode, the module of 
pseudocode implementing at least one copy protection func- 
tion and at least one non-copy-protection function, the 
non-copy-protection function essential to the proper opera- 
tion of the application. 

20. The method as in claim 15, wherein the step of 
providing an encryption/decryption engine comprises pro- 
cessing a coded function of the encryption/decryption 
engine with an obfuscation tool to controllably increase a 
quantity of machine code used to implement the coded 
function. 

21. The method as in claim 15, wherein the encryption/ 
decryption engine encrypts the user data as the user data is 
written to a memory, and decrypts the user data as the user 
data is retrieved from the memory. 
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22. The method as in claim 15, wherein the step of 
providing an ESD simulator comprises using an ESD to 
generate a table of seed and response values, and imbedding 
the table within the appUcation. 
5 23. The method as in claim 15, wherein the ESD generates 
the numeric values using a one-way hash function. 

24. The method as in claim 15, wherein the user data 
comprises 3D animation data. 

25. A computer-readable medium having stored thereon a 
10 software application generated according to the method of 

claim 15. 

26. An application program which operates in conjunction 
with an electronic security device (ESD), the application 
program comprising: 

15 application code which provides end-user functionality; 
an ESD simulator which simulates an operation of the 
ESD, the ESD simulator configured to generate a 
response value based on an input; and 
use restriction code which encrypts and/or decrypts data 
that is essential to the proper operation of the applica- 
tion code using a response value generated by the ESD 
simulator. 

27. The application program as in claim 26, wherein the 
^ use restriction code encrypts and decrypts user data using 

response values generated by the ESD and the ESD simu- 
lator. 

28. The application program as in claim 26, wherein the 
use restriction code generates a seed value using the user 
data, and passes the seed value to the ESD to cause the ESD 
to generate the response value. 

29. The application program as in claim 26, wherein the 
data comprises at least a portion of an authorization 
certificate, the authorization certificate generated by a 

2g license management server. 

30. The application program as in claim 29, wherein the 
license management server encrypts the license certificate 
using a response value generated by the ESD, and the use 
restriction code decrypts the license certificate based on a 

^ response value generated by the ESD simulator. 

31. The application program as in claim 26, wherein at 
least one of the ESD simulator and the use restriction code 
includes pseudocode, and the application program further 
includes an interpreter which executes the pseudocode. 

32. The application program as in claim 26, wherein at 
least one of the ESD simulator and the use restriction code 
includes obfuscated machine code, 

33. The application program as in claim 26, in combina- 
tion with the ESD. 

34. The application program as in claim 33, wherein the 
ESD implements a one-way hash function. 

35. The application program as in claim 26, wherein the 
ESD simulator comprises a table of seed values and asso- 
ciated response values. 

36. The application program as in claim 26, wherein the 
data comprises 3D animation data. 

37. A software application adapted to mn in conjunction 
with a device that implements a cryptographic number 
calculation function, the software application comprising, 
stored on a computer-readable medium: 

application code which generates user data based on the 
input of a user, and which retrieves and processes the 
user data; and 

copy protection code which restricts operation of the 
65 application when the application is executed without 
the device, the copy protection code configured to 
encrypt and/or decrypt the user data using a key that is 
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dependent upon values generated by the device, 44. The software application according to claim 41, 

wherein the device generates the values using the wherein the pseudocode is stored within a data table of the 

cryptographic number calculation function. application. 

38. The software appUcation according to claim 37, 45, The software application according to claim 37, 
wherein the copy protection code includes a simulator which 5 wherein the copy protection code generates seed values 
simulates operation of the device, and wherein the copy ^^ing the user data, and sends the seed values to the device 
protection code further encrypts and/or decrypts the user ^o cause the device to generate the values that are used to 
data using values generated by the simulator. encn^ptand/or encrypt the user data 

39. -nfe software application according to claim 37. ^^^^ ' 
■ . J . . • . J J/ J * J L combmation with the device. 

wherem the user data that IS encrypted and/or decrypted by lO ^^^^^^^ application according to claim 37, 

the copy protection code composes a portion of a tile that is therein the copy protection code includes a copy protection 

written by the application to a memory of a computer. function that is implemented in obfuscated machine code 

40. The software application according to claim 39, generated using an obfuscation tool. 

wherein the copy protection code encrypts the user data as 4g software application according to claim 37, 

the file is written to the memory, and decrypts the user data 15 further comprising a module of obfuscated machine code 

as the file is retrieved from memory. that implements at least one copy -protection function and at 

41. The software application according to claim 37, least one non-copy-protection function, the non -copy- 
wherein at least a portion of the copy protection code is protection function essential to the proper operation of the 
implemented in pseudocode, and wherein the application application, the module of obfuscated machine code gencr- 
includes an interpreter which fetches and executes the 20 ated using an obfuscation tool that controllably increases a 
pseudocode. quantity of machine code. 

42. The software application according to claim 41, 49. The software application as in claim 37, wherein the 
wherein the pseudocode is in a machine language for which cryptographic number calculation function is a one-way 
no publicly available software development tool exists at a hash function. 

time of authoring of the pseudocode portion. 25 50, The software application according to claim 37, 

43. The software application according to claim 41, wherein the user data comprises 3D animation data, 
wherein the pseudocode is encrypted, and the interpreter 

decrypts the pseudocode for execution. ♦ * ♦ * ♦ 



12/10/2003, EAST Version: 1.4,1 



